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INTER PROCESS COMMUNICATIONS IN A 
DISTRIBUTED CP AND NP ENVIRONMENT 

DESCRIPTION 

BACKGROUND OF THE INVENTION 

Field of the Invention 

The present invention generally relates to a method of providing 
lightweight inter process inband communication and, more particularly, to a 
method that allows for information exchange between blades in a network 
processing environment. 

Background Description 

Today's methods of providing inter process communication among 
components in a distributed network processing environment typically 
involves two options: 

(1) External back-plane blade-to-blade ethernet connection, or 

(2) Internet Protocol (IP) stack on each blade. 

External back-plane ethernet connections tend to impact performance while 
implementing an IP stack on each blade increases cost and requires additional 
management. 
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SUMMARY OF THE INVENTION 

It is therefore an object of the present invention to provide a 
lightweight, low cost solution that provides inter process communications 
(IPC) in a network processing environment. 
5 According to the invention, there is provided a method of inter process 

communication (IPC) between processors in a network processing 
environment. The invention comprises software enabled functions that open 
and close inter process communication paths for transmitting and receiving of 
inter process communication frames and software enabled functions that allow 
10 said inter process communication frames to be transmitted to one or several 
processors in the network processing environment. The software has the 
capability of selecting either data or control path in said network processing 
environment to transmit or receive said inter process communication frames. 

BRIEF DESCRIPTION OF THE DRAWINGS 

15 The foregoing and other objects, aspects and advantages will be better 

understood from the following detailed description of a preferred embodiment 
of the invention with reference to the drawings, in which: 

Figure 1 is a block diagram of the Network Processor Transport 
Services (NPTS) in a General Purpose Processor on which the invention may 
20 be implemented; and 

Figure 2 is a flow diagram showing the logic of an implementation of 
the invention. 
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DETAILED DESCRIPTION OF A PREFERRED 
EMBODIMENT OF THE INVENTION 



Referring now to the drawings, and more particularly to Figure 1, there 
is shown a block diagram of a Network Processor Transport Services (NPTS) 
5 100 in a Network Processor. Figure 1 identifies the flows between the NPTS 

components. More particularly, the NPTS 100 comprises a Network Process 
Device Driver (NPDD) 101 and a Physical Transport Device Driver (PTDD) 
102 supported by an Operating System Services (OS Sees) 103. The Operating 
System Services 103 interfaces, through Operating System Interface (OSI), 
10 with the Network Process Device Driver 101 via System Services (Syst Sees) 
l= = 1 04 and with the Physical Transport Device Driver via Physical Transport 

O Services 105. The Physical Transport Device Driver 102 supports a media 

n interface 106. The Physical Transport Services 105 interfaces, through 

Physical Transport Interface (PTI), with the Transport Services 107 of the 
^ 1 5 Network Processor Device Driver 101. The Transport Services 1 07 interfaces, 

through System Services Interface (SSI), with System Services 104 and, 
g through Transport Services Interface (TSI), with internal application 108 and, 

3 additionally through Device Driver Interface (DDI), with external application 

□ 109. 

[aS 20 The role of the NPTS 100 is to provide a transmit/receive function to 

applications which may be internal and external to the Network Processor 
Device Driver (NPPD) 101. Particularly, it entirely hides the nature of the 
underlying Physical Transport Services (PTS) 105. Also, it is the privileged 
interface to communicate with the Network Processor (NP) by handling the 
25 headers necessary to exchange various frame formats. 

The PTS 105 is responsible for handling the transmission and the 
reception of frames on the actual media. It is defined so that it shows a 
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consistent interface to the NPTS 100 regardless the hardware used to 
communicate to the media. The Application Program Interface (API) between 
the NPTS 100 and PTS 105 is made of two functions which are called 
synchronously from each of those two components. As shown in Figure 1 , the 
5 PTS 105 is not part of the NPDD 101. 

The NPTS 100 supports the following frame formats and flows: 
• Control flows based on guided frames 

Data flows based on data frames 

Inter Process Communication (IPC) flows based on data frames 
10 IPC flows are the nature of this invention. This invention consists of APIs 
(Application Program Interfaces) that enable lightweight inter process 
communication in a network processor environment. These APIs and their 
respective functions are (API names are provided for ease of reference): 



API Name 


Function 


np__ts_IPC_register 


Open the software transmit/receive IPC path 
of the NPTS 


np_ts_IPCderegister 


Close the software transmit/receive IPC path 
of the NPTS 


np_ts_sndIPC_unicast 


Transmit an IPC frame to a given processor 
(Control Point identified by a given 
interface, but there is no lookup done on 
ingress side of the Network Processor (NP) 


np__ts_sndIPC_multicast 


Transmit an IPC frame to a set of given 
processors (Control Points) identified by a 
set of given interfaces 



Provided here is sample code that embodies each of these functions. It 
20 should be obvious to those skilled in the art that these functions are just 
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examples and can be structured in several ways to obtain the same result. 



np_ts_IPC_register 
np. return. code, t np. ts.lPC.register( 
np.user.context.t user .context, 
np. user. path, t user. path 

np.return.code.t (*user.rcvlPC_ func)(), 
np.user.handle.t * user. handle); 



Two return codes are received after this function has been called: NP 
received successfully (NP received valid parameters) or NP did not receive 
10 successfully (NP received invalid parameters). The parameters in this function 
called are explained here: 

user_context identified the context for the user. 

user_path identified the control or data path used for this registered IPC. 
userjrcvIPCjFunc is a pointer on the receive data function which is to be 
1 5 called when an IPC frame is received. It must have the following 

prototype: 

np.return.code.t user.rvclPC.func( 

np. user, con text, t user, con text, 
np.Rbuf.s *Rbuf, 
20 np.itf.id_s itf.id); 

- user_context is the user context which was registered. 

- Rbuif is the Raw buffer which contains the received frame. The length 
of the data frame and the address of the start of the frame must be set 
in the Raw buffer. 

25 - itfjd is the source interface identifier which identifies the sender of 
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this IPC frame. 

- userhandle returns an identification of the registered user in the 
NPTS for IPC. 

np_ts_IPC_deregister 
5 np_return_code_ t np_ ts_ IPC_deregister( 

r\p_userj\andiej. userhandle); 

Two return codes are received after this function has been called: NP 
received successfully (NP received valid parameters) or user entry was not 
found by NP (user was not registered). The parameters in this function called 
10 are explained here : 

userhandle identifies the registered user in the NPTS for IPC. 

np_ts_sndIPCjinicast 
np_return_code_t np_ts_sndlPC„uniscast( 
up- user_handle_ t user_hcmdle, 
15 np_Rbuf_s *Rbuf, 

np_ itf_ id_ s / t/L id, 

void (*userCompletion_func)(); 

Two return codes are received after this function has been called: NP 
received successfully (NP received valid parameters) or NP did not receive 
20 successfully (NP received invalid parameters). The parameters in this function 
called are explained here: 

user handle identifies the registered user in the NPTS for IPC. 
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Rbuf is the Raw buffer which contains the IPC frame. The length of the frame 
and the address of the start of the frame must be, set in the Raw buffer. 
itf_id is the interface identifier which corresponds to the destination processor 
to send the IPC frame to. 
5 userComp!etion_func is a pointer on a completion function which is to be 
called at the end of the frame transmission. It is related to the 
ownership of the Raw buffer. 



np_ts_sndIPC_multicast 
np_return„code„t np_ts_sndlPC_uniscast( 
10 np_user_handle_t user-handle, 

np_Rbuf_s *Rbuf, 
np_mid_t mid, 

void (*userCompletion_func)0); 

Two return codes are received after this function has been called: NP 
15 received successfully (NP received valid parameters) or NP did not receive 

successfully (NP received invalid parameters). The parameters in this function 
called are explained here: 

user-handle identifies the registered user in the NPTS for IPC. 
Rbuf is the Raw buffer which Contains tho IPC frame. The length of the 
20 frame and the address of the start of the frame must be set in the Raw 

buffer. 

mid is a multicast identifier which allows to reach a set of destination 
processors. 

userCompIetionfunc is a pointer on a completion function which is to be 
25 called at the end of the frame transmission. It is related to the 
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ownership of tho Raw buffer. 



This invention enables information exchange between processors in a 
network processing environment without requiring an IP stack on each 
General Purpose Processor and not requiring additional overhead (i.e., 
5 external ethernet connection). By providing functions that enable inter process 
communication among processors, software enabled information exchange is 
possible through either data or control paths that physically exist in a NP. 
These functions not only enable processors in an network processing 
environment to communicate amongst each other, but they also enable the end 

10 user to decide which path to transmit information on (i.e., either data or 

control path). If bandwidth is crucial, the data path would be chosen. If high 
priority is crucial, the control path would be chosen. 

Figure 2 illustrates an embodiment of this light-weight IPC protocol 
according to the invention. First, the Open IPC transmit/receive path function 

1 5 is called in function block 20 1 (see np_ts_IPCjregister details previously 

described). Next, a determination is made in decision block 202 as to whether 
receiving or sending an IPC frame. If receiving an IPC frame, the receive IPC 
function is called in function block 203 (see user _rcvIPC_func function 
description in np_ts_IPC_register details previously described). This is 

20 followed by calling the close software transmit/receive IPC path function in 
function block 204 to deregister the IPC path. If sending and IPC frame, a 
determination is made in decision block 205 as to whether it is unicast or 
multicast. If multicast, multicast transmit function is called in function block 
206 (see np_ts_sndIPC_multicast details previously described). This is 

25 followed by calling the close software transmit/receive IPC path function in 
function block 204 to deregister the IPC path. If unicast, unicast transmit 
function is called in function block 207 (see np_te_sndIPC_unicast). This is 
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followed by calling the close software transmit/receive IPC path function in 
function block 204 to deregister IPC path. 

The novel features of this invention are software based functions 
(APIs) that enable inter process communication between processors in a 
5 network processing environment. 

While the invention has been described in terms of a single preferred 
embodiment, those skilled in the art will recognize that the invention can be 
practiced with modification within the spirit and scope of the appended 
claims. 
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